Amiga Collections: Camelot/Camelot 030 (1988-11)(Swedish User Group of Amiga)(SE)(PD)[WB].zip/Camelot 030 (1988-11)(Swedish User Group of Amiga)(SE)(PD)[WB].adf/IFFDevCon/iff_news

Text File | 1988-05-04 | 11KB | 258 lines

                           IFF News - April 1988
                           =====================

                        Carolyn Scheppner - C.A.T.S.


New FORMS and Chunks
====================

New registered IFF FORMS and Chunks described in the current IFF docs:

1. ACBM  (contiguous bitmap form, used for faster loading of ILBMs by Basic)
2. WORD  (word processor FORM, used in ProWrite by New Horizons Software)
3. HEAD  (idea processor FORM, used in Flow by New Horizons Software)
4. DPPV  (perspective Chunk, used in DPaintII by Dan Silva for EA)
5. ANIM  (cel animation FORM, used in Videoscape-3D by Aegis)
         Note - the ANIM spec in the IFF docs is now outdated.  A new
                spec is available.  It will be posted to BIX and will
                appear in the next revision of the IFF manual.



New Registered FORMS to be added to the IFF docs:

1. ANIM  (Revised spec with new compression methods and source examples)
2. PGTB  (ProGram TraceBack diagnostic dump image - John Toebes, S.A.S.)
3. ANBM  (animated bitmap FORM, used in Deluxe Video by Posehn & Case for EA)
4. AIFF  (AudioIFF form for 1 to 32 bit audio samples, by Steve Milne, Apple)
         Note - the AIFF form will only be added to the Amiga IFF docs
                if developers feel it is useful for the Amiga.)



Private Registered FORMs:

1. RGB4 (FORM for 4 bit R G B pixel information)

   COMP (chunk containing compression table for the FORM)

   The RGB4 FORM contains a BMHD which will specify 2 as its Compression.
   BMHD compression value 2 has been reserved for this algorithm
   which is a modified Huffman encoding.

2. C100 - Cloanto Italia (private word processing form)
          Chunks C1C0, C1K0, C1F0, C1U0, C1K1
          C1C0 and C1K0 used in C100 forms
          C1F0 and C1U0 used in C100 and FTXT forms
          Also SGR9    SGR29  (label start and end)

3. SHAK - Used by Shakespeare, Infinity Software (private)
          Contains embedded ILBMs




New Unregistered Private ILBM chunks:

These chunks appear in ILBMs created with Photon Paint and are described in
the Photon Paint manual.

1. BHSM
   Note: This chunk appears first in the ILBM, before the BMHD,
         breaking some programs which assumed that BMHD would be first.
2. BHCP



Additional Reserved Names:

1. CAT CLIP - to hold various representations of data clipped to clipboard
2. ARC - an archiving form proposed on Usenet
3. ATXT, PTXT, CODE, PROG - temporarily reserved




Errata and Additions to the Original EA IFF Specs
=================================================

1. EA has reserved two new sEvents for SMUS since the IFF release which
   appears in the Addison-Wesley manuals:

          SID Value                        Next Data Byte
          =========                        ==============
   #define SID_Clef   135          0=treble, 1=bass, 2=alto, 3=tenor
   #define SID_Tempo  136          beats per second (0-255)


2. In DPaintII, Dan Silva has defined bit 1 (next to lowest bit) of
   the CRNG cycling chunk "active" variable as a flag for reverse
   color cycling.  If this bit is set, cycle direction is reversed.
   Unfortunately, DPaintII internally uses rate <= RNG_NORATE (36)
   to mean that a cycle range is inactive, and is not too careful
   about the value saved in the CRNG.active variable.  This makes
   it impossible to determine programatically whether or not a DPaint
   pic should be cycled.


3. The embedded ILBM forms in an ANIM do not adhere to the ILBM spec
   and technically should have had a different chunk ID.  They do
   not contain the required ILBM property BMHD, and instead contain
   an ANHD and delta information for changing the previous image.
   This inconsistency occurred because the original ANIM concept of
   sequential ILBMs was slowly modified, for speed and compactness,
   into a single ILBM followed by frames containing encoded animation
   changes.  After much discussion with the authors and third parties
   supporting the ANIM form, it was decided that this inconsistency
   must remain to avoid breaking existing products.




ILBM Problem Areas
==================

Thanks to John Bittner of the Zuma Group for organizing much of this
information in our amiga.dev/iff conference on BIX.


1. PageWidth and PageHeight - Overscan or Not ?

   There are two sets of variables in an ILBM which describe the size
   of the picture.  The image dimensions are stored in w and h.  The
   other two variables, pageWidth and pageHeight, have been interpreted
   in different ways by the various applications which create ILBMs.

   The ILBM spec describes them as follows:

   "The size in pixels of the source "page" (any raster device) is stored
   in pageWidth and pageHeight, e.g. (320,200) for a low resolution Amiga
   display.  This information might be used to scale an image or to
   automatically set the display format to suit the image.  (The image can
   be larger than the page.)"


   DPaintII stores the normal Amiga screen size in pageWidth and pageHeight,
   and the image size (which may be larger) in w and h.  Up until now,
   we have maintained that this is the correct use of these variables
   because it preserves the normal screen dimensions for programs which
   wish to clip or scroll larger images in a normal size display.
   In addition, storage of the normal screen size makes it possible for
   the correct ViewModes to be determined in the absence of an Amiga
   ViewModes CAMG chunk.

   However, a number of other applications which save overscan images
   store the full size of their display ViewPort in the pageWidth and
   pageHeight variables, and there seems to be a growing consensus
   that this is the correct use of these variables.  This approach is
   non-Amiga-specific and preserves the artist's intent of the size
   raster in which the image was meant to be displayed.

   For now, flexible ILBM readers should be prepared to deal with
   with either alternative, and must parse CAMG chunks for the
   correct Amiga ViewModes.  If a CAMG chunk is not present, ViewModes
   must be guessed based on the pageWidth and pageHeight, with width
   greater than or equal to 640 assumed HIRES, and height greater than
   or equal to 400 assumed LACE.



2. The Use and Misuse of the CAMG chunk

   The "optional" ILBM chunk CAMG holds the Amiga ViewModes for displaying
   the image contained in an ILBM.

   With the current variety of overscan storage methods, and the introduction
   of HAM and HALFBRITE paint packages, it is extremely important that
   all Amiga ILBM readers and writers save and parse this chunk.  I have
   actually seen HALFBRITE ILBMs with NO CAMG chunk!  I guess the reader
   programs are supposed to see that it's 6 bitplanes and toss a coin to
   decide if it's HAM or HALFBRITE.   Please store CAMG chunks in all
   ILBMs and parse them when reading ILBMs.

   When saving and parsing the CAMG chunk, you should be aware that certain
   ViewMode bits can cause problems for display programs which use the
   CAMG contents directly for Screen or View modes.  It has been suggested
   that the following scattered bits be masked out when reading or writing
   a CAMG chunk:  SPRITES, VP_HIDE, GENLOCK_AUDIO, and GENLOCK_VIDEO.


3. CRNG Color Cycling chunks - Active or Not ?

   DPaintII, by default, seems to save CRNG chunks which contain cycle
   ranges and are marked as active, regardless of whether a picture is
   meant to be cycled.  This makes it impossible for a cycling display
   program to reliably identify ILBMs which should not be cycled.
   Internally, DPaintII interprets a cycle rate <= 36 (RNG_NORATE)
   to mark a cycle range as non-active.  Even if some version of
   DPaint corrects this problem, it will not correct the CRNG chunks
   of thousands of ILBMs in the hands of users.  I made my last
   Display program cycle automatically and accept CNRG.rate <= 36
   as inactive.  I also wrote a utility for the IFF disk which could
   deactivate CRNG chunks.  But I found myself repeatedly faced with
   cycling King Tuts and Mona Lisas and never any time to fix the files.
   So I gave up on automatic cycling, and made it a command line or
   ILBM icon ToolType option.  I retained my old logic to decide if
   individual CRNG's should be cycled or not.


4. How many colors should a CMAP contain ?

   There seems to be a great deal of variation in the size of the CMAP
   stored in HAM ILBMs by various applications.  Some store only the
   number of absolute colors used in that particular HAM ILBM.  Programs
   that do this better be really careful about following the IFF spec
   rules regarding the padding between odd-sized chunks.  Some store the
   maximum number of absolute colors in a HAM display (16).  Some store
   a full palette of 32, and many may store a palette of 64 because the
   supplied IFF example code generically uses 1<<bitmap->depth when
   calculating the size CMAP to write.  ILBM display programs must be
   careful to not blindly accept and set the number of color registers
   provided in a CMAP.



A Word about Compatibility
==========================

   There have been several incidences of new ILBM graphic products
going to market and then being found incompatible with major existing
ILBM graphic software.  Before releasing any product which saves IFF
files of any type, please test the compatibility of your files by
loading them into the major existing software products which read
and write files of the same type, and try loading the files created by
other applications.  If you do not have access to a large number of
these other products, try to find people who do and arrange file exchanges
and compatibility tests.  If your product adapts to PAL screen sizes
or clock rate (important in audio period calculations), arrange for
your product to also be tested on a PAL system.

   Be especially careful if you are not using the EA supplied IFF reading,
writing, and compression routines.  This can sometimes lead to the creation
of subtly out-of-spec IFF files which are rejected by products which use
the IFF code supplied by EA.  Some examples would be odd length chunks
not followed by a pad byte or a reader not designed to handle pad bytes.
Another would be a badly compressed ILBM.  The EA compresser is smart and
does not encode a scan line if encoding would result in more bytes.  The EA
decompressor expects a smartly compressed file, and will return an error if
handed an encoded line more than one control byte larger than destination
scan line.  If you are not using the EA IFF code, please make sure that your
code follows all of the rules.



Future IFF
==========

   We hope to see a shared run-time iff.library sometime this year, either
done in-house or by a third party.  Such a library would contain all of
the core IFF reading and writing routines, and perhaps some higher level
ILBM routines.  Such a library would take a lot of the IFF code burden
off of applications, and would be especially useful for Basic programmers.